\section{Heur\'istica de Neilsen}

Con la finalidad de asegurarnos de que el sistema que se ha dise\~{n}ado se adapta a cualquier tipo de usuario y es \'util y utilizable se ha seguido, como se indica en {\em Human-Computer Interaction} \cite{human-computer} la heuristica de Neilsen.
Dicha heur\'istica es un conjunto de reglas que es aconsejable seguir en el momento de plantear un sistema desde el punto de vista del usuario.
Las reglas que a continuaci\'on se mencionan ayudan a conseguir el objetivo de un sistema interactivo pero no siempre son infalibles ya que se deben tener en cuenta m\'as aspectos que los mencionados a continuaci\'on.
{\small
\begin{itemize}
\item1.	Visibilidad del estado del sistema
\item2.	Comunicaci\'on entre el sistema y el mundo real
\item3.	El control del usuario y la libertad
\item4.	Consistencia y est\'andares
\item5.	Prevenci\'on de errores
\item6.	Ayudar al usuario a reconocer, diagnosticar y recuperarse de los errores
\item7.	Reconocimiento antes que recordar
\item8.	Flexibilidad y eficiencia de uso
\item9.	Dise\~{n}o minimista
\item10.Ayuda y documentaci\'on
\end{itemize}
}

\begin{itemize}

\item {\bf Visibilidad del estado del sistema:} Una pr\'actica com\'un e incorrecta cuando se realiza una interficie de usuario es confiar que el usuario se acordar\'a de que est\'a haciendo en cada una de las pantallas de las que se compone nuestra aplicaci\'on. Por ejemplo: si le decimos al usuario que en la pantalla siguiente deber\'a introducir su DNI y posteriormente cambiamos de pantalla, no podemos asegurar que el usuario seguir\'a acord\'andose de que le pedimos anteriormente que insertara su DNI, puesto que en dicho momento puede haberse ausentado o simplemente puede haber avanzado a la siguiente pantalla sin tener intenci\'on de hacerlo. Es por esa raz\'on que en nuestro sistema siempre debe haber una indicaci\'on del estado del sistema actual, no solamente un mensaje indicando que est\'a haciendo en cada momento el usuario , si no que cada vez que se presiona alg\'un bot\'on o se realiza alguna acci\'on debe haber consecuencias suficientemente l\'ogicas para el usuario y alg\'un cambio en la interficie de usuario con tal de que este se percate de que se ha cambiado la acci\'on que estaba realizando.


\item {\bf Comunicacion entre el sistema y el mundo real:} Los dise\~{n}adores y programadores de un sistema, tienden a utilizar un lenguaje t\'ecnico para comunicarse con el usuario final.Tambi\'en disponemos de otra vertiente para el mismo problema que consiste en utilizar descripciones muy similares para funciones del sistema no tan similares. Esto crea confusi\'on en el usuario que desea utilizar la aplicaci\'on en cuesti\'on. Es por ello que el lenguaje que se debe utilizar al comunicarse con el usuario a trav\'es de la interficie ha de ser lo m\'as simple y menos ambiguo posible para as\'i evitar confusiones innecesarias a quien use dicho programa.

\item {\bf El control del usuario y la libertad:}  Como bien sabemos, la mayor parte de los usuarios aprenden el funcionamiento de un sistema a base del llamado m\'etodo de prueba y error. Es por eso que es muy probable que a cualquier tipo de usuario que utilice nuestro sistema puedan aparecerle pantallas que no se esperaba, y por ello debemos tener siempre en mente que al igual que un usuario necesita que las diferentes funcionalidades del programa est\'en a la vista para poder utilizarlas sin buscar demasiado, tambi\'en debemos asegurar que todas las acciones que se realicen dentro del programa podr\'an deshacerse para as\'i no privar al usuario de la libertad de investigar. No obstante, tambi\'en debemos asegurar de que existen salidas r\'apidas para poder evitar realizar acciones elegidas sin querer.


\pagebreak


\item {\bf Consistencia y est\'andares:} Para que un usuario no tenga que aprender nuevos tipos de funcionamientos para nuestro programa en especifico, una buena pr\'actica es aplicar el mismo principio de funcionamiento que alguna otra aplicaci\'on ya utilizada por todo el p\'ublico. Por ejemplo: si realizamos un procesador de texto, para seleccionar algunas palabras del texto que un usuario est\'a editando, la manera m\'as natural de hacerlo es presionando la primera palabra y arrastrando hasta la \'ultima, tal y como se hace en {\em Microsoft Office},{\em Open Office} o {\em TextWorks}.

\item {\bf Prevenci\'on de errores: } Por supuesto, nuestro sistema no deber\'ia de tener ning\'un error que no fuera transparente para el usuario. Pero hay ocasiones en las que es inevitable que surja alg\'un tipo de error el cual afecte, en consecuencia, al usuario final. En estas situaciones es una buena pr\'actica detectar antes de que se produzca el error en la medida de lo posible e intentar solucionarlo sin que tenga que intervenir el usuario, es por ello que se recomienda no obviar los errores, si no convivir con ellos y tener en cuenta que en cualquier momento pueden suceder para poder detectarlos a tiempo y poder solucionarlos.

\item {\bf Ayudar al usuario a reconocer, diagnosticar y recuperarse de los errores:} Si el error no se puede evitar, como mencionaba anteriormente, lo que se debe hacer es explicar al usuario, de forma sencilla, lo que est\'a sucediendo en el sistema para que pueda entenderlo y proporcionar una serie de herramientas que le den la posibilidad al usuario de solucionar dicho error sin provocar mucha molestia.

\item {\bf Reconocimiento antes que recordar: }  Una de las razones por las que un usuario puede verse desmotivado en el momento de aprender a utilizar un programa es que las funcionalidades del sistema no est\'en a primera vista. Esto es, que tenga que recordar donde se hallaba una opci\'on en vez de poder verla en pantalla de un vistazo. Es por ello que los botones que realizan acciones clave de nuestro sistema deben estar siempre a la vista y deben tener un nombre descriptivo, as\'i como no deben haber por ejemplo m\'as de 7 categor\'ias de men\'us diferentes ya que la visi\'on humana solo puede atender a un m\'aximo de siete elementos diferentes a la vez.

\item {\bf Flexibilidad y eficiencia de uso:} Una de las cosas que hace que un usuario experto siga usando la aplicaci\'on que un programador ha desarrollado es los aceleradores. Esto es, para cada funcionalidad, a\~{n}adir diversas maneras de llevarlas a cabo, algunas muy intuitivas y m\'as lentas, para los usuarios noveles y otras menos intuitivas pero mucho m\'as r\'apidas, para los usuarios expertos.

\pagebreak

\item {\bf Dise\~{n}o minimalista: } Si al dise\~{n}ar la interficie de usuario ponemos demasiados activadores o men\'us, la aplicaci\'on se ver\'a sobrecargada de funcionalidades en pantalla. De este modo, el usuario no podr\'a atender a todas las posibilidades que tiene delante y por lo tanto no se sentir\'a c\'omodo en el momento de utilizar la aplicaci\'on.

\item {\bf Ayuda y documentaci\'on:} Para complementar todas las reglas que se mencionan anteriormente, se recomienda el desarrollo de una consistente documentaci\'on de usuario. En esta deben mencionarse todos los aspectos a tener en cuenta incluyendo en el las preguntas frecuentes que pueden surgir por un usuario novel en el programa.

\end{itemize}

Durante el proceso de dessarrollo, al final de cada iteraci\'on, se procedi\'o a evaluar si el programa cumplía con los requisitos indispensables para que el usuario pueda usarlo sin problemas, siguiendo heurística explicada anteriormente.